The CIM model of software is an open standard that controls how an IT environment represents managed elements. CIM is similar to an object-oriented standard for IT environments that assists in managing multiple elements that are not necessarily from the same manufacturer or provider. Multiple parties, such as administrators, can exchange management information using a common interface, as well as actively control the managed objects using the same CIM interface. Use of the common interface reduces the need to utilize expensive conversion operations and complex software.
The CIM standard originates with the Distributed Management Task Force (“DTMF”). This CIM standard is used by a plurality of parties to distribute their own implementation of CIM. The DTMF also promulgates its own CIM implementation, the Web-Based Enterprise Management (“WBEM”). The Common Information Model Object Broker (“CIMOM”) brokers CIM objects between a number of sources and destinations. A CIM object should be a representation, or model, of a managed resource, such as a printer, disk drive, or central processing unit (CPU). In at least one CIM implementation, such as the Pegasus implementation, CIM objects are represented internally as C++ classes. The CIMOM transfers information between WBEM clients, the CIM Object Manager Repository, and managed resources.
FIG. 3 illustrates a sample CIM architecture 300 including management infrastructure 310 and CIM providers 325 and 335. The management infrastructure 310 includes CIMOM 315 and a CIMOM object repository 320. CIMOM 315 provides applications with uniform access to management data. Providers 325, 335 function as intermediaries between CIMOM 315 and managed objects 340, 345. Managed objects 340, 345 are any appropriate managed objects or systems, such as computer systems, computer networks, monitors, printers, databases, or the like. The providers 325, 335 supply CIMOM 315 with data from managed objects 340, 345, handle requests on behalf of management applications 310, and generate event notifications.
When a request is made from management application 310 for information about one of the managed systems 340, 345, CIMOM 315 retrieves information about the class from the CIM repository 320 and the requested information is returned. Based on the information returned, CIMOM 315 either secures the information from the CIM repository 320 or providers 325, 335. Several types of providers that can plug into the management infrastructure 310, such as Class, Instance, and Property providers are defined in CIM implementations. Class providers define the corresponding Management Object, or class, in the CIMOM object repository 320 and identify and populate instances of this class. Instance providers define the instances of a pre-defined Management Object and populate their properties with the values obtained or pertinent to the instances of the corresponding managed objects. If the object definition changes, the instance provider code must also be changed accordingly. Property providers supply the properties of a certain category of managed objects to the management infrastructure. These properties should be mapped to instances of some Managed Objects outside and independently of the provider, generally through a MOF script.
While CIM implementations are a valuable asset to the development community, the multiplicity of implementations leads to incompatible implementations. Thus, it is common for development projects, especially discontinuous projects performed by disparate vendors, to encounter compatibility issues.
Currently, CIM schema MOFs from the DMTF website are not completely compatible with the Windows WMI CIMOM. This is because most of the CIM MOFs are tested with Pegasus CIMOM. But when using the WMI CIMOM, the CIM schema and provider MOFs must be edited to meet the rules and requirements for WMI CIMOM on Windows. Currently, there is no program or tool that will do this for the user. So the user must manually edit the MOF files to make them compatible with Windows WMI.
Integrations with the WMI+A components on Windows require multiple steps, such as the steps that follow. While the steps as described assume that the actual providers will be either Pegasus C++ (implicitly managed by the PPA<TODO: link>) or CMPI (implicitly managed by the CPA<TODO: link>), other steps are required where this assumption is not satisfied.
First, the qualifiers must be amended to ensure compatibility. Provider qualifiers are used to link a native WMI provider with a class in the WMI repository. The WMI+A stack includes an internal registration provider that will dynamically place this qualifier on any class registered by provider. There is no need for Pegasus and CMPI providers to add this qualifier to their classes.
The keys must be declared to ensure compatibility. The CIM standard only allows one class in a hierarchy to declare keys. Once a class has declared a property a key, subclasses can not add or remove keys. The WMI compiler is very strict on this rule. In a subclass, you can not mark a property that is a key redundantly.
Example: (GOOD)
class Parent{ [key] string Identifier;};class Child : Parent{ string NewProperty; // new non-key properties are okay};
Example (BAD):
class Parent{ [key] string Identifier;};class Child : Parent{ [key] string Identifier; // redundant key definition is technically legal but willbe rejected by mofcomp string NewProperty; // new non-key properties are okay};
Since some of the DMTF MOFs redundantly mark some properties as keys, they will need to be edited to remove the redundant key qualifier. The MOFs should compile as expected on WMI and other compilers such as Pegasus's cimmof. Overrides are still allowed.
Windows requires methods to have the Implemented qualifier when a provider supports a given method. This is simple when the class a provider supports also defines the method, but more complex when the method is inherited. When a subclass implements a method defined by a parent class, many times just adding the Implemented qualifier for the method in the subclass causes the mofcomp error WBEM_E_PROPAGATED_METHOD. This error means that an attempt was made to reuse an existing method name from a parent class and the signatures do not match. During the mofcomp of the parent class on Windows, an additional information of ToSubClass is added to method signatures, resulting in a mismatch causing an error. Currently, to address this issue, two MOFs are needed for these scenarios, one for Windows and one for non-Windows systems. The Windows MOF file has this additional information of ToSubClass added for the subclass method so that the mofcomp does not complain.
All classes that are not managed by a provider or the repository (i.e., static instances), should have the Abstract qualifier. There are some rare exceptions to this such as when a parent classes already has this qualifier and marked it as non-overrideable, but that will not be covered here. The purpose of the qualifier is to tell WMI there is no provider.
Example (GOOD):
[Abstract]
class Sample_ParentClass{ string Id;};class Sample_ChildClass : Sample_ParentClass{};
This is most often needed when one creates a new namespace and adds a standard CIM schema, which only marks some classes as Abstract. On Windows, it's best to simply mark all standard CIM classes (those that start with CIM_) as Abstract.
<TODO: Link to Sample Shell Script>
Example (BAD):
//left out abstract
class Sample_ParentClass{ string Id;};class Sample_ChildClass : Sample_ParentClass{};
In some translations, calls such as enumeratelnstance appear to succeed but the call is never passed to the PPA/CPA and, consequently, the provider. Most often the WMI return code is WBEM_S_NO_ERROR yet 0 instances are returned. When the Abstract and Provider-Dynamic qualifiers are missing from a class, WMI acts as the default provider for it and uses the repository to store the information. And, since in WMI subclass only overrides parents (not adding new instances), there is no need to query subclasses if the parent returns 0 instances. It is possible that if the parent had 1 instance, then subclasses would be called to check for any overrides. Explicitly adding the Abstract qualifiers to unmanaged classes can resolve this problem.
All “standard” CIM indications derive from WMIA_ExtrinsicEvent, which derives from_ExtrinsicEvent. This is necessary to link WMI's internal alerting mechanisms to that of the standards', and to scope that link to the WMI+A stack only.
In short, the translator must compile the MOF to create the namespace, compile the schema MOF into the namespace, compile the provider schema into the namespace, run cimsubscribe for the subscriptions and filters, and compile the registration MOFs. This is a long and tedious process especially where the exemplary MOF includes hundreds of CIM schema MOFs.
First, the process requires changes to compile DMTF Parent CIMv211 MOFs using Windows WMI mofcomp tool:
1. comment out from cimv211.mof: //#pragma include (“Network/CIM_DNSSettingData.mof”)
2. Add IN and OUT qualifiers on some of the classes to fix errors
3. Need to remove KEY qualifier on all the classes.
Next, the process requires changes on the user provider MOFs in order for the provider to work with WMI. These changes include copying the methods from parent MOFs (CIM Schema MOFs) to child MOFs (user provider MOFs) and adding the qualifier Implemented to each method. Additionally, the IN(false) and OUT(false) text are removed from all methods in the parent MOFs (CIM schema MOFs) and child MOFs (user provider MOFs) and the qualifier abstract is added to all the parent CIM schema MOFs. Other specific errors arise using third party MOFS, and windows wbemtest can be used to copy methods from a parent class into a child class, as well as removing other key qualifiers and removing out certain namespace mismatches for root addresses.
Despite these known steps, there has been a long felt need to improve the speed and cost of performing such steps. It is therefore a challenge to develop strategies for providing MOF compatibility among various CIM implementations to overcome these, and other, disadvantages.